IBIS Macromodel Task Group Meeting date: 25 July 2017 Members (asterisk for those attending): ANSYS: Dan Dvorscak * Curtis Clark Broadcom (Avago): Xingdong Dai * Bob Miller Cadence Design Systems: * Ambrish Varma Brad Brim Kumar Keshavan * Ken Willis eASIC: David Banas Marc Kowalski Ericsson: Anders Ekholm GlobalFoundries: Steve Parker IBM Luis Armenta Trevor Timpane Intel: * Michael Mirmak Keysight Technologies: * Fangyi Rao Radek Biernacki Ming Yan Maxim Integrated Products: Hassan Rafat Mentor, A Siemens Business: John Angulo * Arpad Muranyi Micron Technology: * Randy Wolff Justin Butterfield SiSoft: Walter Katz Todd Westerhoff * Mike LaBonte Synopsys: Rita Horner Kevin Li Teraspeed Consulting Group: Scott McMorrow Teraspeed Labs: * Bob Ross TI: Alfred Chong The meeting was led by Arpad Muranyi. -------------------------------------------------------------------------------- Opens: - None. ------------- Review of ARs: - None. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: - Arpad: Does anyone have any comments or corrections? [none] - Ambrish: Motion to approve the minutes. - Mike L.: Second. - Arpad: Anyone opposed? [none] ------------- New Discussion: BIRD189: - Discussion: Arpad introduced two topics that had been the subject of email discussions and discussions in the Interconnect Task Group meetings. The subjects were how to terminate any unused ports in the Touchstone or ISS Models used in an Interconnect Model, and the question of reference terminals. Bob Ross noted that most of these discussions would be handled in Interconnect meetings, but some discussion could be done in ATM in case certain people only attended ATM meetings. Arpad recapped some public and private email threads over the previous week in which many people had given their input on s-parameter termination. Arpad noted that his bottom-line conclusion was that perhaps we should revert to using the built in reference impedance values in the Touchstone file (version 1, or version 2). The question was then what to do with IBIS ISS models, which have no equivalent concept. Bob noted that discussions had gone back and forth on using the Touchstone reference impedance(s) and that using them might be easier than other solutions, but this left the issue of getting different answers than ISS models that lack the concept of a reference impedance. Arpad noted that one option might be to add a parameter to IBIS-ISS that would act like the Touchstone reference impedance. Bob noted that he and Radek had concerns about using the Touchstone reference impedance, which is why this had become a big decision. Ken asked if there was universal agreement that this is a spec issue instead of an issue for EDA tools. He noted that tools offer the user various options for terminating unused terminals. He said we'd been dealing with similar issues with connector models for quite some time. He suggested this might be handled with a note that tools may have various options for termination. Arpad agreed that this was a valid point, but said he thought it was important to address it in the spec because the Interconnect Models have a Sub-Param Number_of_terminals, which does not have to match the number of terminals in the underlying Touchstone file. Therefore, we need to at least mention in the spec that the possibility for unused ports in the underlying model exists. Arpad also noted that he thought the concept of the unused ports in the underlying model was that we wanted to pretend they don't exist. He said this seemed like a different concept than simply terminating a port to model an impedance mismatch or some physical connection. Ambrish asked if this discussion could have any bearing on BIRD158. Arpad said he didn't think so, because BIRD158 shouldn't involve any unused ports. Bob R. noted that reference terminal discussions could affect BIRD158. Arpad agreed, and said the first order issue of the discussions was the termination value and the second order issue was the reference terminal. Mike L. suggested that the model maker can only advise on what to do in this case. Since the spec is giving the facility for the model maker to provide this advice, the reference impedance the model was made with seems like a good piece of information to provide. However, he did not think the spec should be prescribing any termination requirements. Arpad said at some point we would need to arrive at a collective decision. Arpad noted that we might consider removing the Unused_port_termination Sub-Param and section altogether. The group agreed to continue discussions in the Wednesday Interconnect meetings. BIRD166.3: - Discussion: In Walter's absence, Arpad noted that BIRD166.3 had been formally submitted to the Open Forum. He asked everyone to review it. Arpad and Curtis noted that they had spoken with Walter and confirmed that this new draft intentionally removed all changes from the time domain section. Therefore, this new draft changes the sequencing so that the Rx1 Init() output is convolved with the downstream channel prior to calling Rx2 Init(), but it makes this change only for the statistical flow. The Init() flow portions of the statistical and time domain flows are different in BIRD166.3. Bob R. noted that there was no markup with BIRD166.3, so it was hard to see what was changed. BIRD190: - Discussion: Ambrish said he wanted to move forward with this, but he didn't want to proceed without Walter here. Ambrish noted that BIRD 190 merely states a warning. He noted that Radek had suggested changing the "note" to "warning" in the previous meeting. Ambrish said he thought a "note" was a statement of fact, and a "warning" said to watch out for something that may or may not happen. Arpad noted that we don't have a hard rule that says the ATM must make a recommendation on every BIRD that is submitted to the Open Forum. Ambrish said he preferred to have some consensus recommendation from ATM, though it need not be unanimous. Bob R. said one big problem was that both BIRD166 and BIRD190 could be presented to the Open Forum, but if they contained mutually exclusive changes there could be a collision if both were approved. Arpad and Curtis noted that BIRD166 and BIRD190 didn't necessarily overlap anymore, as BIRD190 only affected time domain flow and the new BIRD166.3 only affected statistical flow. Fangyi noted that he still had problems with BIRD166.3. In statistical flow it caused an explosion in the number of crosstalk IR terms that had to be presented to each successive Init() call in the chain. In general, the lack of the self-response of each channel causes problems later if they are needed. He said that a loop couldn't be handled without the self-IR because you only get to call Init() once for each device. Michael M. asked if we were back to this being a problem with doing more than just initialization in Init(), and asked if we needed a separate function for IR modification for statistical flow. Arpad noted that merely separating the initialization and simulation portions of the Init() function would not solve this flow problem. If the simulation portion of the current Init() function were simply moved to a new function, the same problems would exist. Fangyi said this was one possible option, and you could pass Init() and this new function different inputs. Ken suggested that this would be pretty major surgery for a ten-year- old spec. He said this issue was like anything else, and that you had simple models that couldn't do everything and more complex models that were needed for more complex tasks. He felt it was unnecessary to try to make Init() only models handle complex repeater chain simulations. BIRD191.1: - Bob R.: [sharing BIRD191.1 draft email] - Changed the title of the BIRD to "Clarifying Locations for Si_location and Timing_location" - Abided by suggestions from the previous meeting. - Removed the new "Buffer" location that was proposed in the original BIRD191. - The existing spec. has "Die" and "Pin" locations ("Pin" is default). - This revisions states that "Die" will always mean the buffer location, even if an Interconnect Model has separate buffer, pad, and pin locations. - The existing "Die" is really the same as buffer terminal in the existing spec, i.e., there is no concept of on-die interconnect prior to BIRD189. - Four reasons for making this simplifying assumption are stated in the Background Information/History at the end of the BIRD191.1 text. - Michael M.: Do we view this as something that has to be resolved, as part of the interconnect proposal, for IBIS 7.0? - Arpad/Bob R.: Yes, it's related to BIRD189 so it would be good to deal with it simultaneously. - Arpad: It's probably not a show stopper for BIRD189, but there could be some ambiguity without this BIRD. - Arpad: How does this relate to [External Circuit] or [External Model]? - In those multi-lingual sections we talk about where to probe the waveform. We mention "pad", but now that pad is not the only thing on the die and we also have buffer terminal, we may need to redefine these choices. - Bob R.: We don't support [External Circuit] with Interconnect Models, so I think we don't have an issue with [External Circuit]. - Arpad: Right, that may eliminate this issue for [External Circuit]. - Bob R.: I will think about effects on [External Model]. - Arpad: Bob R. and I will look into this issue offline. - Mike L.: Motion to adjourn. - Curtis: Second. - Arpad: Thank you all for joining. AR: Bob R. and Arpad to look into any BIRD191.1 interaction with [External ***]. ------------- Next meeting: 01 August 2017 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives